1. Field of the Invention
The present invention relates generally to System-on-Chip (SoC) design, and in particular, to a method and apparatus for modeling a model necessary for the simulation which is performed prior to the design of a SoC.
2. Description of the Related Art
System-on-Chip (SoC) is composed of many elements such as processor, timer, interrupt controller, bus, memory, and embedded Software (eSW). The elements were realized in a single board just several years ago. At present, however, they can be fully realized in one circuit with the development of the semiconductor technology.
Today, for the system design necessary for SoC design, there is a need for an automatization tool required for the analyzing of the system architecture and verifying hardware and software.
In addition, as a degree of integration of chips has recently increased with the progress of the process technology, the design complexity of SoC also increases. The increase in the design complexity of the SoC technology increasingly needs a decrease in the time to market (TTM) and an increase in the design quality. To meet these needs, several methods for a variety of SoC modeling have been proposed, and a Transaction Level (TL) model method is the typical SoC modeling method. The TL model is a method for abstracting a Register Transfer Level (RTL) model in various levels to increase the design productivity and increase the simulation speed.
The use of the TL model, as it increases the simulation speed, enables even the architecture exploration and/or the performance estimation, contributing to an increase in the design quality.
The TL model-based design method is classified into a top-down approach method and a bottom-up approach method.
FIG. 1 illustrates top-down approach and bottom-up approach methods used for designing the general SoC system.
A top-down approach 100 is an approach method for designing a TL model 104 in a higher level and then refining it for realization. This can be usefully used for developing a new block. A bottom-up approach 102 is an approach method for modeling an existing RTL model 106 with a higher-level language to make the TL model 104. This is useful for higher-level simulation performed in the situation where the RTL model block has already been developed. Transaction Level Modeling (TLM) is a high-level modeling scheme that separately manages the realization of the functional unit or communication mechanism, and the inter-module communication. The TLM and the RTL model need a transactor to communicate with each other. The transactor serves to convert transaction into an RTL signal, or otherwise convert an expression level into transaction.
No matter whether the SoC designer uses the top-down approach 100 or the bottom-up approach 102 when performing modeling, the equivalence between the results of the TL model 104 and RTL model 106 should be guaranteed in order to trust the results on the TL model simulation.
Generally, during SoC design, the TL model can be consistent in operation with the RTL model according to the purpose of the modeling, but cannot be fully consistent with the RTL model in the cycle-by-cycle operation. In addition, the TL model, when it is used for software development, is occasionally modeled only as a partial function of the RTL model. Therefore, it is hard to use the formal equivalence check that performs mathematical modeling on the actual operation of the model rather than the simulation and determines if the mathematical model is equivalent. In this case, therefore, the equivalence between the results of the TL model and the RTL model is checked by the method of determining if there are equivalent outputs for the applied inputs, using the simulation method shown in FIG. 2.
FIG. 2 illustrates a process of performing modeling using a simulation method during the general SoC design.
A test vector 200 means an input necessary for verifying a SoC simulation modeling method, and is input to a TL model simulator 202 and a first transactor (Transactor #1) 206. The first transactor 206 outputs the input test vector to an RTL model simulator 204. Because the first transactor 206 needs more detailed information than the input test vector 200 to perform the lower-level RTL model, the first transactor 206 serves to add supplemental information thereto and output it to the RTL model simulator 204.
As described above, the TL model simulator 202, as it is a higher-level model, is faster than the RTL model. Therefore, the TL model simulator 202 directly receives the test vector 200 without any transactor, and then outputs the TL model simulation result thereon to a second transactor (Transactor #2) 208. In this case, because the output of the TL model simulator 202 is a higher-level output, the second transactor 208 generates, as a lower-level output, the higher-level simulation result received to maintain the equivalent level to that of the output of the RTL model simulator 204 that outputs the lower-level output.
A comparison unit (or comparator) 210 determines whether the output of the equivalent-level RTL model simulator 204 is equivalent to the simulation result of the second transactor 208, and if they are equivalent to each other, the comparator 210 can perceive that the modeling for successful simulation has been performed.
However, if the simulation method of FIG. 2 is used to perform modeling method verification for the SoC design, an unsuspected corner case may occur. To prevent the corner case, there is a need for a large number of test vectors such as the constrained random test vector, which is a tool for randomly automatically generating the test vector. After simulating the large number of test vectors, it is almost impossible for the human being to compare the results one by one with the naked eye. Therefore, there is a need for an automatization tool. However, even the use of the recently commercialized automatization tool can hardly automate the verification because of the characteristic that the RTL model simulator 204 and the TL model simulator 202 are not fully consistent with each other in terms of the cycle-by-cycle operation.
FIG. 3 is a timing diagram illustrating outputs given when the equivalent test vector 200 is input to the TL model simulator 202 and the RTL model simulator 204.
The desired result to be obtained through the general SoC design simulation results of FIG. 2 and FIG. 3 is to verify SoC design simulation by determining if the two simulators read the equivalent data from the equivalent addresses of the memory even though the equivalent test vector is input to the TL model simulator 202 and the RTL model simulator 204.
Generally, if an Advanced High-performance Bus (AHB) bus protocol is analyzed, the simulation result of the RTL model and the simulation result of the TL model are consistent with each other in operation.
Shown in FIG. 3 is the result obtained by simulating an operation in which the RTL model simulator 204 and the TL model simulator 202 read data from the memory for SoC realization.
In FIG. 3, the shown signals are signals used in the AHB, and HADDR, HTRANS, HRDATA and HREADY are result values of the TL/RTL model simulators; their definitions are given below.                HADDR: address of the memory        HTRANS: control signal indicating validity of HADDR        HRDATA: data that the TL/RTL model simulators have actually read from the memory        HREADY: control signal indicating whether the data actually read from the memory is valid. For example, HREADY=‘1’ for Valid, and HREADY=‘0’ for Invalid.        
A clock (CLK) 300 is input to the TL/RTL model simulators along with the test vector.
It can be noted in FIG. 3 that two exemplary model simulators of the TL model simulator 202 and the RTL model simulator 204 both read data D0, D1, D2, D3 and D4 from memory addresses A2, A3, A4, A8 and AC.
FIG. 4 illustrates a process of comparing HADDR, HTRANS, HRDATA, and HREADY signals every cycle to verify the general SoC model simulation results. That is, the process shown in FIG. 4 reads signals from waveforms every cycle and compares the signal values.
In step 400, the RTL model simulator 204 and the TL model simulator 202 read in step 400 the HADDR, HTRANS, HRDATA and HREADY signals in FIG. 3 from the waveforms of the input signals every cycle. If the next cycle has started in step 402, the comparator 210 compares values of the signals read by the RTL model simulator 204 and the TL model simulator 202 in step 404.
However, even though the comparator 210 simply compares the equivalent signals in every cycle as described above to check the consistency between the signals read by the RTL model simulator 204 and the TL model simulator 202 in the general method, the results of the two simulations may not be equivalent to each other every time. For example, it can be seen that even as to HADDR of FIG. 3, at a clock cycle C1, HADDR of the RTL model simulator 204 is A0, but HADDR of the TL model simulator 202 is 9C.
Aside from the foregoing method of comparing the result of the RTL model simulator 204 with the result of the TL model simulator 202 every cycle, there is a method of comparing only the sequences as shown in FIG. 5.
FIG. 5 illustrates a method for comparing sequences to verify the general SoC model simulation result. In the sequence comparison process, the RTL model simulator 204 and the TL model simulator 202 read signals from waveforms in step 500, and push the signal values into their First Input First Output (FIFO) registers in step 504 every time the signal values of the waveforms change in step 502. In step 506, the comparator 210 reads the signal values pushed into the FIFO registers, and compare the read signal values, thereby comparing the sequences.
However, the sequence comparison method shown in FIG. 5 is also not accurate. It can be appreciated from the timing diagram of FIG. 3 that a sequence of HADDR among the output signal values of the RTL model simulator 204 includes 9C, A0, A2, A3, A4, A8, AC and B0, and a sequence of HADDR among the output signal values of the TL model simulator 202 includes 9C, A2, A3, A4, A8, AC and B0. That is, because the sequence of the output signal HADDR of the RTL model simulator 204 is different from the sequence of the output signal HADDR of the TL model simulator 202, even though the modeling results are actually consistent with each other, there is no currently available method capable of perceiving this fact.